Rust: Path resolution before variable resolution - #20716

Path resolution needs to happen before variable resolution, because otherwise we cannot know whether an identifier pattern binds a new variable or whether it refers to a constructor or constant:

let x = ...; // `x` is only a variable if it does not resolve to a constructor/constant

Even though variable names typically start with a lowercase letter and constructors/constants with an uppercase letter, this is not enforced by the Rust language.

Variables may shadow declarations, so variable resolution also needs to affect path resolution:

fn foo() {}        // (1)

fn bar() {
    let f = foo;   // `foo` here refers to (1) via path resolution
    let foo = f(); // (2)
    foo            // `foo` here refers to (2) via variable resolution
}

So it may seem that path resolution and variable resolution must happen in mutual recursion, but we would like to keep the inherently global path resolution logic separate from the inherently local variable resolution logic. We achieve this by

• First computing global path resolution, where variable shadowing is ignored, exposed as the internal predicate resolvePathIgnoreVariableShadowing.
• resolvePathIgnoreVariableShadowing is sufficient to determine whether an identifier pattern resolves to a constructor/constant, since if it does, it cannot be shadowed by a variable. We expose this as the predicate identPatIsResolvable.
• Variable resolution can then be computed as a local property, using only the global information from identPatIsResolvable.
• Finally, path resolution can be computed by restricting resolvePathIgnoreVariableShadowing to paths that are not resolvable via variable resolution.

DCA looks good: We get a (somewhat surprisingly) large increase in Percentage of calls with call target, and a (less surprisingly) increase in results for rust/unused-variable. I spot checked some of the new alerts on rust and rust-ffmpeg, and while they are FPs, opening those files in VS Code with Rust analyzer also results in warnings. So instead of attempting to filter away the results in the query, I would like to keep them in, as they are generally very useful for finding bugs/shortcomings in path resolution (such as this one).